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Foreword 

This Technical Specification has been produced by the 3"* Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The objective of this document is to address the Inter-IMS Network to Network Interface (II-NNI) consisting of Ici and 
Izi reference points between IMS networks in order to support end-to-end service interoperability. 

The present document will address the issues related to control plane signalling (3GPP usage of SIP and SDP protocols, 

required SIP header fields) as well as other interconnecting aspects like security, numbering/naming/addressing and 
user plane issues as transport protocol, media and codecs actually covered in a widespread set of 3GPP specifications. A 
profiling of the Inter-IMS Network to Network Interface (II-NNI) is also provided. 

Charging aspects will be addressed as far as SIP signalUng is concerned. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 

non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version apphes. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 
[2] IETF RFC 791: "Internet Protocol" . 

[3] 3GPP TS 23.002: "Network architecture". 

[4] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 
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Subsystem (IMS) based on Session Initiation Protocol (SIP) and Session Description Protocol 
(SDP); Stage 3". 

[7] IETF RFC 2460: "Internet Protocol, Version 6 (IPv6) Specification". 
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[9] 3GPP TS 22.228: "Service requirements for the IP multimedia core network subsystem". 

1 10| 3GPP TS 33.210: "3G security; Network Domain Security (NDS); IP network layer security". 

[I I] 3GPP TS 26.1 14: "IP Multimedia Subsystem (IMS); Mulfimedia Telephony; Media handhng and 
interaction". 

[12] ETSI TS 181 005 1.1.1: "Teleconnmunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Services and Capabilities Requirements". 

[13] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[14] IETF RFC 3966: "The tel URI for Telephone Numbers". 

[15] IETF RFC 3860: "Common Profile for Instant Messaging (CPIM)". 

[16] IETF RFC 3859: "Common Profile for Presence (CPP)". 
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3 Definitions, symbols and abbreviations 
3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
TR 21.905 [1]. 

example: text used to clarify abstract rules by applying them literally. 

EM CN subsystem: (IP Multimedia CN subsystem) comprises of all CN elements for the provision of IP multimedia 
appUcations over IP multimedia sessions, as specified in 3GPP TS 22.228 [9]. 

IP multimedia session: as specified in 3GPP TS 22.228 [9] an IP multimedia session is a set of multimedia senders and 
receivers and the data streams flowing from senders to receivers. IP multimedia sessions are supported by the IP 
multimedia CN Subsystem and are enabled by IP connectivity bearers (e.g. GPRS as a bearer). A user can invoke 
concurrent IP multimedia sessions. 

non-roaming II-NNI: the II-NNI between IMS home networks. 

roaming II-NNI: the II-NNI between a visited IMS network and the IMS home network. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [120J apply: 
MSC Server enhanced for ICS 



3.2 Symbols 

For the purposes of the present document, the following symbols apply: 



Ici 


Reference Point between an IBCF and another IBCF or I-CSCF belonging to a different IM CN 




subsystem network 


Izi 


Reference Point between a TrGW and another TrGW or media handUng node belonging to a 




different IM CN subsystem network 


Mi 


Reference Point between a BGCF and CSCF 


Mm 


Reference Point between a CSCF/BGCF/IMS ALG and an IP multimedia network. 


Mw 


Reference Point between a CSCF and another CSCF 


Mx 


Reference Point between a CSCF/BGCF/MSC Server enhanced for ICS and IBCF 



3.3 Abbreviations 



For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 



ACR 


Anonymous Communication Rejection 


B2BUA 


Back 2 Back User Agent 


BGCF 


Breakout Gateway Control Function 


CAT 


Customized Alerting Tone 


CB 


Communication Barring 


CCBS 


Completion of Communications to Busy Subscriber 


CCNR 


Communication Completion on No Reply 


CDIV 


Communication Diversion 


CDIVN 


Communication Diversion Notification 


CRS 


Customized Ringing Signal 


ECT 


Explicit Communication Transfer 


FA 


Flexible Alerting 


HOLD 


Communication HOLD 


CW 


Communication Waiting 
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IBCF 


Interconnection Border Control Function 


ICB 


Incoming Communication Barring 


ICS 


IMS Centralized Services 


I-CSCF 


Interrogating CSCF 


n-NNi 


Inter- IMS Network to Network Interface 


IM 


Instant Messaging 


IMS-ALG 


IMS Application Level Gateway 


MCID 


Malicious Communication IDentification 


MRFC 


Media Resource Function Controller 


MSRP 


Message Session Relay Protocol 


MWI 


Message Waiting Indication 


NA(P)T-PT 


Network Address (Port-Multiplexing) Translation-Protocol Translation 


NNI 


Network to Network Interface 


OCB 


Outgoing Communication Barring 


OIP 


Originating Identification Presentation 


OIR 


Originating Identification Restriction 


P-CSCF 


Proxy CSCF 


PNM 


Personal Network Management 


PRES 


Presence 


TIP 


Terminating Identification Presentation 


TIR 


Terminating Identification Restriction 


TrGW 


Transition Gateway 



4 Overview 

Interconnection between two different IM CN subsystems shall be guaranteed in order to support end-to-end service 
interoperability. For this purpose, Inter-IMS Network to Network Interface (II-NNI) between two IM CN subsystem 
networks is adopted, according to the assumptions coming from 3GPP TS 23.002 [3] and 3GPP TS 23.228 [4]. 

Aiming to support the delivery of IMS services between two separated IM CN subsystems, protocol interconnection has 
to occur: 

- at a control plane level, in order that IMS procedures can be supported. In this case the adopted reference point is 
the Ici; and 

- at a user plane level, where media streams are exchanged over the Izi reference point. 

The management of IP multimedia sessions is acted by using SIP. The transport mechanism for both SIP session 
signalling and media transport is IPv4 (IETF RFC 791 [2]) or IPv6 (IETF RFC 2460 [7]). The 3GPP profile of SIP 
defining the usage of SIP within the IM CN subsystem is specified in 3GPP TS 24.229 [5]. Example call flows are 
provided in 3GPP TR 24.930 [6]. 

The general interconnection model is shown in Figure 4.1. 




Figure 4.1 : Interconnection lUlodel for IM CN subsystems 

The possible functional entities involved in the signalling plane intercormection (IBCF, I-CSCF, P-CSCF, BGCF and 
MSC Server enhanced for ICS) and in the user plane interconnection (TrGW) are specified in 3GPP TS 24.229 [5], in 
3GPP TS 24.292 L121J and in 3GPP TS 29.162 [8]. 

IP Version interworking is described within 3GPP TS 29.162 [8]. 
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5 Reference model for interconnection between IIVI CN 
subsystems 

5.1 General 

Figure 5.1 illustrates the architecture diagram given in 3GPP TS 23.228 [4] showing the Inter-IMS Network to Network 
Interface (11-NNI) between two IM CN subsystem networks. 



P-CSCF 



S-CSCF 




l-CSCF 


BGCF 


\ 


1 

T 


y^Mx 



MSG Server 
enhanced 
for ICS 




BGCF 


l-CSCF 




S-CSCF^ 



Mx^^ Mx 



IcM 



JI-NNI 



Signalling 

Bearer 




P-CSCF 



ix 4- 



^ ^Mx 



TrGW 



MSG Server 
enhanced 
for ICS 



IM CN subsystem network A IM CN subsystem network B 



Figure 5.1.1 : Inter-IMS Network to Network Interface between two IM CN subsystem networks 

The protocols over the two reference points Ici and Izi make up the Inter-IMS Network to Network Interface. 

The Ici reference point allows IBCFs to communicate with each other in order to provide the communication and 
forwarding of SIP signalling messaging between IM CN subsystem networks. The Izi reference point allows TrGWs to 
forward media streams between IM CN subsystem networks. 

IMS roaming performed by using II-NNI is considered, when the IBCFs are inserted at the network borders. 

Whenever the Inter-IMS Network to Network Interface is used to interconnect two IM CN subsystem networks 
belonging to different security domains, security procedures apply as described in 3GPP TS 33.210 [10]. 



5.2 Functionalities performed by entities at the edge of the 
network 

5.2.1 Interconnection Border Control Function (IBCF) 

An IBCF provides application specific functions at the SIP/SDP protocol layer in order to perform interconnection 
between IM CN subsystem networks by using Ici reference point. According to 3GPP TS 23.228 [4], IBCF can act both 
as an entry point and as an exit point for a network. 

The functionalities of IBCF are indicated in the 3GPP TS 23.228 [4] and specified in 3GPP TS 24.229 [5]. They 
include: 

- network topology hiding; 

application level gateway (for instance enabling communication between IPv6 and IPv4 SIP applications, or 
between a SIP application in a private IP address space and a SIP application outside this address space); 

controlhng transport plane functions; 

controlling media plane adaptations; 
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screening of SIP signalling information; 

- selecting the appropriate signalling interconnect; and 

- generation of charging data records. 

Based on local configuration, the IBCF performs transit routing functions as specified in 3GPP TS 24.229 [5]. 
The IBCF acts as a B2BUA when it performs IMS-ALG functionaUty. 



According to 3GPP TS 23.002 [3], the TrGW is located at the network borders within the media path and is controlled 
by an IBCF. Forwarding of media streams between IM CN subsystem networks is applied over Izi reference point. 

The TrGW provides functions like network address/port translation and IPv4/IPv6 protocol translation. NAT-PT binds 
addresses in IPv6 network with addresses in IPv4 network and vice versa to provide transparent routing between the 
two IP domains without requiring any changes to end points. NA(P)T-PT provides additional translation of transport 
identifier (TCP and UDP port numbers). The approach is similar to that one described also in 3GPP TS 29.162 [8]. 

Further details are described in 3GPP TS 23.228 [4]. 



6.1 Definition of Inter-IIVIS Network to Network Interconnection 
6.1 .1 SIP methods and header fields 



The functional entity closest to the border of an II-NNI (see reference model in Clause 5) shall provide the capabihties 
specified for that network element in Annex A.2 of 3GPP TS 24.229 [5] with modifications as described in the 
following sub-clauses. 

6.1.1.2 SIP methods 

3GPP TS 24.229 [5] defines the methods allowing an IBCF to interconnect to an IBCF placed in another IM CN 
subsystem. 

The following SIP methods are supported on the II-NNI as defined in table 6.1. 

The following table is based on Table A.5 and Table A. 163 of 3GPP TS 24.229 [5] and endorsed for this document: 



5.2.2 Transition Gateway (TrGW) 



6 



Control plane interconnection 



6.1.1.1 



General 
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Table 6.1 : Supported SIP methods 



Item 


Method 


Ref. 


il-NNI 








Sending 


Receiving 


1 


ACK request 


IETF RFC 3261 [13] 


m 


m 


2 


BYE request 


IETF RFC 3261 [13] 


m 


m 


3 


BYE response 


IETF RFC 3261 [13] 


m 


m 


4 


CANCEL request 


IETF RFC 3261 [13] 


m 


m 


5 


CANCEL response 


IETF RFC 3261 [13] 


m 


m 


5A 


INFO request 


IETF RFC 6086 [39] 








5B 


INFO response 


IETF RFC 6086 [39] 








8 


INVITE request 


IETF RFC 3261 [13] 


m 


m 


9 


INVITE response 


IETF RFC 3261 [13] 


m 


m 


9A 


MESSAGE request 


IETF RFC 3428 [19] 








9B 


MESSAGE response 


IETF RFC 3428 [19] 








10 


NOTIFY request 


IETF RFC 3265 [20] 


Cl 


cl 


11 


NOTIFY response 


IETF RFC 3265 [20] 


Cl 


cl 


12 


OPTIONS request 


IETF RFC 3261 [13] 


m 


m 


13 


OPTIONS response 


IETF RFC 3261 [13] 


m 


m 


14 


PRACK request 


IETF RFC 3262 [18] 


m 


m 


15 


PRACK response 


IETF RFC 3262 [18] 


m 


m 


15A 


PUBLISH request 


IETF RFC 3903 [21] 


Cl 


cl 


15B 


PUBLISH response 


IETF RFC 3903 [21] 


cl 


cl 


16 


REFER request 


IETF RFC 3515 [22] 








17 


REFER response 


IETF RFC 3515 [22] 








18 


REGISTER request 


IETF RFC 3261 [13] 


c2 


c2 


19 


REGISTER response 


IETF RFC 3261 [13] 


c2 


c2 


20 


SUBSCRIBE request 


IETF RFC 3265 [20] 


cl 


cl 


21 


SUBSCRIBE response 


IETF RFC 3265 [20] 


cl 


cl 


22 


UPDATE request 


IETF RFC 331 1 [23] 


m 


m 


23 


UPDATE response 


IETF RFC 3311 [23] 


m 


m 


c1: 


In case of roaming scenario, the support of the method is m, else o. 


c2: 


In case of roaming scenario, the support of the method is m, else n/a. 


NOTE: 


In the above table, m, o and c and n/a have the meanings indicated in Table 6.3 



6.1.1.3 SIP header fields 

6.1.1.3.0 General 

The IBCF shall provide the capabilities to manage and modify SIP header fields according to section 5.10 and Annex A 
of 3GPP TS 24.229 [5] with modifications as described in the following sub-clauses. 

6.1 .1 .3.1 Trust and no trust relationship 

The IBCF acting as exit point applies the procedures described in clause 5.10.2 of 3GPP TS 24.229 [5] before 
forwarding the SIP signalling to the IBCF acting as entry point. The IBCF acting as entry point applies the procedures 
described in clause 5.10.3 of 3GPP TS 24.229 [5]. 

Additionally, in case there is no trust relationship between the two IM CN subsystems connected by II-NNI, the IBCF 
acting as exit point apphes the procedures described in clause 4.4 of 3GPP TS 24.229 [5], before forwarding the SIP 
signalling to the next IBCF acting as an entry point. The IBCF acting as an entry point applies the procedures described 
in clause 5.10.3 of 3GPP TS 24.229 [5]. 

These procedures may be utilized on a per header field basis to realize overall trust as well as per service level screening 
of header fields. Trust relationships and trust domains may be defined by inter-operator agreements for individual 
services and/or individual SIP header fields. 

The management of the SIP header fields (if present) over II-NNI in case of a presence or not of a trust relationship 
between the two intercormected IM CN subsystems is wrapped up in the following table. 
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Table 6.2: Management of SIP header fields over ll-NNI in presence or not of a trust relationship 



Item 


Header field 


Reference 


Trust relationship 


Not trust relationship 


1 


P-Asserted-ldentity 


IETF RFC 3325 [44] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 
(NOTE 5) 


As specified in 3GPP TS 24.229 
[5], clause 4.4 
(NOTE 5) 


2 


P-Access-Network- 
Info 


IETF RFC 3455 [24] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


3 


Resource-Priority 


IETF RFC 441 2 [78] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


4 


History-Info 


IETF RFC 4244 [25] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in Clause 4.3.3 of 
RFC 4244 [25] and in 3GPP TS 
24.229 [5], clause 4.4 


5 


P-Asserted-Service 


draft-drage-sipping- 
service-identification 
[26] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 
(NOTE 3) 


As specified in 3GPP TS 24.229 
[5], clause 4.4 
(NOTE 3) 


6 


P-Charging-Vector 


IETF RFC 3455 [24] 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


As specified in 3GPP TS 24.229 
[5], clause 5.10 


7 


P-Charging- 
Function-Addresses 
(NOTE 4) 


IETF RFC 3455 [24] 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


As specified in 3GPP TS 24.229 
[5], clause 5.10 


8 


P-Profile-Key 
(NOTE 2) 


IETF RFC 5002 [64] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


9 


P-Private-Network- 
Indication 
(NOTE 1 ) 


draft-vanelburg- 
sipping-private- 
network-indication 
[84] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


10 


P-Served-User 
(NOTE 1 , NOTE 2) 


IETF RFC 5502 [85] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


11 


Reason (in a 
response) 


IETF RFC 6432[49] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 

[5], clause 4.4 


12 


P-Early-Media 


IETF RFC 5009 [74] 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


NOTE 1 
NOTES 

note: 

NOTE-; 
NOTE e 


: For a roaming ll-NNI, a trust relationship with respect to this header field is required. 
I: This header field is only applicable on a roaming ll-NNI. 
i: In addition, value-dependent operator policies may be applied. 

This header field is not applicable at ll-NNI. 
>: The handling of the URI parameters "cpc" and "oli", defined in 3GPP TS 24.229 [5] subclause 7.2A.12, is 

specified in 3GPP TS 24.229 [5], clause 4.4. 



6.1 .1 .3.2 Derivation of applicable SIP header fields from 3GPP TS 24.229 [5] 

For any method in Table 6.1, the SIP header fields applicable on the II-NNI are detailed in the corresponding method 
tables for the UA role and proxy role sending behaviour in Annex A of 3GPP TS 24.229 [5]. Unless other information 
is specified in the normative part of the present specification, the applicability of header fields at the II-NNI can be 
derived for each method from the corresponding tables in Annex A of 3GPP TS 24.229 [5] as follows: 

All header fields not present in the corresponding tables in Annex A of 3GPP TS 24.229 or marked as "n/a" in 
both the "RFC status" and "profile status" columns for the UA role and proxy role sending behaviour of that 
tables are not appUcable at the II-NNI. 

NOTE 1 : Operators could choose to apply header fields for new SIP extensions on an II-NNI based on bilateral 

agreements, but this is outside the scope of the present specification. 

- All header fields which are marked as "o" in at least one of the "RFC status" or the "profile status" profile 
columns for the sending behaviour in the corresponding UA role and proxy role tables in Annex A of 3GPP TS 
24.229 [5] and as "n/a" or "o" in the other such columns are appUcable at II-NNI based on bilateral agreement 
between operators. 
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All header fields which are marked as "m" in at least one of the "RFC status" or the "profile status" columns for 
the sending behaviour in the corresponding UA role or proxy role table in Annex A of 3GPP TS 24.229 [5] and 
as "n/a", "o", or "m" in the other such columns are applicable at the II-NNI. 

- If conditions are specified, they are also applicable at the II-NNI and the above rules are applicable to the "n/a", 
"o" and "m" values within the conditions. 

NOTE 2: In the above rules, the RFC profile columns are taken into account in order to enable interworking with 
non-3GPP networks. 

An informative summary of SIP header fields to be used over the II-NNI is proposed in Annex A. 

6.1 .1 .3.3 Applicability of SIP header fields on a roaming II-NNI 

The following SIP header fields are only applicable on a roaming 11-NNl: 
Authentication-Info 

- Authorization 

- P-Associated-URI 

- P-Called-Party-ID 

- P-Preferred-Service 

- P-Profile-Key 
P-Served-User 

- P-Visited-Network-ID 

- Path 

- Proxy-Authenticate 
Proxy- Authorization 

- Service-Route 

- www-Authenticate 

6.1 .1 .3.4 Applicability of SIP header fields on a non-roaming II-NNI 

Void 

6.1.1.4 Notations of the codes 

In the table 6.1 the status codes "m", "o", "c" and "n/a" have the following meanings: 
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Table 6.3: Key to notation codes for SIP messages 



Notation 
code 


Notation name 


Sending side 


Receiving side 


m 


mandatory 


The message shall be supported at II- 
NNI. 

Supporting sending a SIP message at 
the ll-NNI means that this message shall 
be sent over the ll-NNI if received from 
the serving network. It does not imply 
that network elements inside the serving 
network or user equipment connected to 
this network shall support this message. 


Supporting receiving a SIP message at 
the ll-NNI means that this message shall 
be forwarded to the serving network. It 
does not imply that network elements 
inside the served network or user 
equipment connected to this network are 
supporting this message. 





optional 


The message may or may not be 
supported at ll-NNI. The support of the 
method is provided based on bilateral 
agreement between the operators. 


Same as for sending side. 


n/a 


not applicable 


It is impossible to use/support the 
message. 


It is impossible to use/support the 
message. This message will be discarded 
by the IBCF. 


c 

<integer> 


conditional 


The requirement on the message ("m", 
"o" or "n/a") depends on the support of 
other optional or conditional items. 
<integer> is the identifier of the 
conditional expression. 


Same as for sending side. 



6.1.1.5 Modes of signalling 

Overlap signalling may be used if agreement exists between operators to use overlap and which method to be used, 
otherwise enbloc shall be used at the II-NNI. 

6.1.2 SDP protocol 
6.1.2.1 General 

The functional entity closest to the border of an II-NNI (see reference model in Clause 5) shall provide the capabiUties 
specified for that network element in Annex A.3 of 3GPP TS 24.229 [5]. 

6.1.3 Major capabilities 

This subclause contains the major capabiUties to be supported over the II-NNI. 

The table 6.1.3.1 specifies which capabilities are appUcable for II-NNI. The profile status codes within table 6.1.3.1 are 

defined in table 6.1.3.2. 

For the "Basic SIP" capabilities part of table 6.1.3.1, the last column "Profile status over II-NNI" specifies the general 
status of applicability of the IETF RFC 3261 [13] main mechanisms described in the 2"'' column "Capability over the 
Ici". 

For the "Extensions to basic SIP" capabilities part, the last column "Profile status over ll-NNI" specifies the general 
status of applicabiUty of the RFC referenced in the 2°'' column "Capability over the Ici". 

If necessary, the appUcability of RFCs at the II-NNI level is further detailed in the present Technical Specification. 

The columns "Reference item in 3GPP TS 24.229 [5] for the profile status" provide informative references for 
comparison purposes into the UA and Proxy role major capabilities tables in 3GPP TS 24.229 [5], where the 
capabilities are defined via additional references. 
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Table 6.1.3.1 : Major capabilities over ll-NNI 



Item 


Capability over the Ici 


Reference item in 3GPP 
TS 24.229 [5] for the 
profile status 


Profile 
status over 

II MMI 
ll-NHI 


1 lA Rnio 
/MOTE 1^ 


riOAy rule 
/MOTE 2^ 




Raeif QID MUTE REP M11\ 








1 


reyisTraTions 


1 , d, c.r\ 




c^ 


o 


initiating a session 


do, o, 4 




m 


3 


terminating a session 


5 


3 


m 


4 


General proxy beliaviour 




4, 5, 14, 15, 

1 y r 


n/a 


5 


IVlanaging several responses due to forking 


9,10 


6 


m 


6 


support of indication of TLS connections in the Record-Route 

header 




7, 8 


n/a 


7 


Support of authentication 


~7 O OA 

/, o, oA 


O A 

oA 


c2 


8 


Timestamped requests (Timestamp header field) 


c 
D 




m 


9 


Presence of date in requests and responses (Date header 
field) 


1 1 


Q 

y 


m 


\ 1) 


Presence of alerting information data (Alert-info header field) 


12 


10 





-i -1 


Support and handling of the Require header field for 
rituib 1 tri ana oiner requesis or responses lor meinoas 
other than REGISTER 




11, lii, To 


m 


1 o 
1 ^ 


ouppori ano reauing or ine oupponeo ana unsupponea 




1 fi 17 1 ft 
1 O, 1 / , 1 O 


m 


13 


Support of the Error-Info header field in 3xx - 6xx responses 


- 


19 





■1 A 


Support and handling of the Organization header field 




1 yA, lyK 


m 




Support and handling of the Call-Info header field 




1 y 1 yu 


m 


16 


Support of the Contact header field in 3xx response 


- 


19E 


m 




Extensions to basic SIP 








H "7 
1 / 


lb 1 r HrL- faUob toaj. oir iNrU method ana package 
framework 


13 


20 





1 /A 


lb 1 r Kru buob [oyj. legacy iNrU usage 


13A 


20A 





18 


IETF RFC 3262 [18]: reliability of provisional responses in 
oir (rKAuiN. metnou) 


14 


21 


m 


19 


IETF RFC 3515 [22]: the SIP REFER method 


15 


22 





20 


IETF RFC 3312 [40] and RFC 4032 [41]: integration of 
resource management and SIP (Preconditions framework) 


16 


23 





21 


IETF RFC 331 1 [23]: the SIP UPDATE method 


17 


24 


m 


22 


IETF RFC 3313 [42]: SIP extensions for media authorization 
(P-Media-Authorization header field) 


19 


26 


n/a 


23 


IETF RFC 3265 [20]: SIP specific event notification 
(SUBSCRIBE/NOTIFY methods) 


20, 21, 22, 
23 


27, 28 


Cl 


24 


IETF RFC 3327 [43]: session initiation protocol extension 
header field for registering non-adjacent contacts (Path 
header field) 


24 


29 


c2 


25 


IETF RFC 3325 [44]: private extensions to the Session 
Initiation Protocol (SIP) for network asserted identity within 
trusted networks 


25 


30 


c4 


26 


IETF RFC 3325 [44]: the P-Preferred-ldentity header field 
extension 


- 


- 


n/a 


27 


IETF RFC 3325 [44]: the P-Asserted-ldentity header field 
extension 






c4 


28 


IETF RFC 3323 [34]: a privacy mechanism for the Session 
Initiation Protocol (SIP) (Privacy header field) 


26, 26A, 
26B, 26C, 
26D, 26E, 
26F, 26G, 
26H 


31 , 31A, 
31B, 31C, 
31D, 31E, 
31F, 31G, 
31H 


m 


29 


IETF RFC 3428 [19]: a messaging mechanism for the 
Session Initiation Protocol (SIP) (MESSAGE method) 


27 


33 





30 


IETF RFC 3608 [45]: session initiation protocol extension 
header field for service route discovery during registration 
(Service-Route header field) 


28 


32 


c2 


31 


IETF RFC 3486 [46]: compressing the session initiation 
protocol 


29 


34 


n/a 


32 


IETF RFC 3455 [24]: private header extensions to the 


30 


35 
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session initiation protocol for the 3rd-Generation Partnership 

Project {3GPP) 








32A 


IETF RFC 3325 [44]: act as first entity within the trust domain 
for asserted identity 


30A 


30A 


n/a 


32B 


IETF RFC 3325 [44]: act as entity within trust network that 
can route outside the trust network 


30B 


30B 


n/a 


32C 


IETF RFC 3325: act as entity passing on identity 
transparently independent of trust domain 


30C 


30C 


n/a 


33 


IETF RFC 3455 [24]: the P-Associated-URI header field 
extension 


31 


36 


c2 


34 


IETF RFC 3455 [24]: the P-Called-Party-ID header field 
extension 


32 


37 


c2 


35 


IETF RFC 3455 [24]: the P-Visited-Network-ID header field 

extension 


33 


38, 39 


c2 


36 


IETF RFC 3455 [24]: the P-Access-Network-lnfo header field 
extension 


34 


41 , 42, 43 


c4 


37 


IETF RFC 3455 [24]: the P-Charging-Function-Addresses 

header field extension 


35 


44, 44A 


n/a 


38 


IETF RFC 3455 [24]: the P-Charging-Vector header field 
extension 


36 


45, 46 


Cl 


39 


IETF RFC 3329 [47]: security mechanism agreement for the 
session initiation protocol 


37 


47 


n/a 


39A 


draft-dawes-dispatch-mediasec-parameter [134]: Capability 
Exchange for Media Plane Security 


37A 


47A 


n/a 


40 


IETF RFC 3326 [48]: the Reason header field for the session 

initiation protocol 


38 


48 





41 


IETF RFC 6432 [49]: carrying Q.850 codes in reason header 
fields in SIP (Session Initiation Protocol) responses 


38A 


48A 


c4 


42 


IETF RFC 3581 [50]: an extension to the session initiation 
protocol for symmetric response routeing 


39 


49 





43 


IETF RFC 3841 [51 ]: caller preferences for the session 
initiation protocol (Accept-Contact, Reject-Contact and 

i~» X r~\ • "x" 1 _i 1 I \ 

Request-Disposition header fields) 


40, 40A, 
40B, 40C, 
40D, 40E, 
40F 


50, 50A, 
50B, 50C, 
50D, 50E, 
50F 


m 


44 


IETF RFC 3903 [21]: an event state publication extension to 
the session initiation protocol (PUBLISH method) 


41 


51 


cl 


45 


IETF RFC 4028 [52]: SIP session timer (Session-Expires and 
Min-bE headers) 


42 


52 


m 


46 


IETF RFC 3892 [53]: the SIP Referred-By mechanism 


43 


53 


m 


47 


IETF RFC 3891 [54]: the Session Initiation Protocol (SIP) 
Replaces header 


44 


54 





48 


IETF RFC 391 1 [55]: the Session Initiation Protocol (SIP) 

"Join" header 


45 


55 





49 


IETF RFC 3840 [56]: the callee capabilities 


46 


56 





50 


IETF RFC 4244 [25]: an extension to the session initiation 
protocol for request history information (History-Info header 
field) 


47 


57 





51 


IETF RFC 5079 [57]: Rejecting anonymous requests in the 
session initiation protocol 


48 


58 





52 


IETF RFC 4458 [58]: session initiation protocol URIs for 
applications such as voicemail and interactive voice 
response (NOTE 3) 


49 


59 





53 


IETF RFC 4320 [59]: Session Initiation Protocol s (SIP) non- 
INVITE transactions 


50 


61 


m 


54 


IETF RFC 4457 [60]: the P-User-Database private header 
field extension 


51 


60 


n/a 


55 


IETF RFC 5031 [61]: a uniform resource name for services 


52 


62 


n/a 


56 


IETF RFC 5627 [62]: obtaining and using GRUUs in the 
Session Initiation Protocol (SIP) 


53 


63 


cl 




Void 








58 


IETF RFC 4168 [27]: the Stream Control Transmission 
Protocol (SCTP) as a Transport for the Session Initiation 
Protocol (SIP) 


55 


65 





59 


IETF RFC 5002 [64]: the SIP P-Profile-Key private header 

field extension 


56 


66, 66A, 
66B 


c3 


60 


IETF RFC 5626 [65]: managing client initiated connections in 
SIP 


57 


67 


cl 
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61 


IETF RFC 5768 [66]: indicating support for interactive 
connectivity establisliment in SIP 


58 




n/a 


62 


IETF RFC 5365 [67]: multiple-recipient MESSAGE requests 
in the session initiation protocol 


59 


69 


if 29, else 

n/a 


63 


draft-ietf-sipcore-location-conveyance-08 [68]: SIP location 
conveyance (Geolocation header) 


60 


70, 70A, 
70B 


m 


64 


IETF RFC 5368 [69]: referring to multiple resources in the 
session initiation protocol 


61 


71 


if 19, else 

n/a 


65 


IETF RFC 5366 [70]: conference establishment using 
request-contained lists in the session initiation protocol 


62 


72 





66 


IETF RFC 5367 [71]: subscriptions to request-contained 
resource lists in the session initiation protocol 


63 


73 


if 23, else 
n/a 


67 


IETF RFC 4967 [72]: dialstring parameter for the session 
initiation protocol uniform resource identifier 


64 


74 


c2 


68 


IETF RFC 4964 [73]: the P-Answer-State header extension 
to the session initiation protocol for the open mobile alliance 
push to talk over cellular 


65 


75 





69 


IETF RFC 5009 [74]: the SIP P-Early-Media private header 
field extension for authorization of early media 


66 


76 


c4 


70 


IETF RFC 4694 [75]: number portability parameters for the 

'tel' URI 


67, 67A, 
678 


77, 77A, 
77B 





72 


IETF RFC 441 1 [77]: extending the session initiation protocol 
Reason header for preemption events 


69 


79 





73 


IETF RFC 4412 [78]: communications resource priority for 
the session initiation protocol? (Resource-Priority header 

field) 


70, 70A, 
70B 


80, 80A, 
80B 





74 


IETF RFC 5393 [79]: addressing an amplification 
vulnerability in session initiation protocol forking proxies 


71 


81 


m 


75 


IETF RFC 5049 [80]: the remote application identification of 
applying signalling compression to SIP 


72 


82 


n/a 


76 


IETF RFC 5688 [81]: a session initiation protocol media 
feature tag for MIME application sub-types 


73 


83 


Cl 


77 


IETF RFC 6050 [26]: Identification of communication 
services in the session initiation protocol 


74 


84, 84A 





78 


IETF RFC 5360 [82]: a framework for consent-based 

communications in SIP? 


75, 75A, 
75B 


85 





79 


draft-]ohnston-sipping-cc-uui-09 [83]: transporting user to 
user information for call centers using SIP? 


76 


86 


cl 


80 


1 X J. II 1" J.I X i 1' I t\ A V A1 T" 1 

draft-vanelburg-dispatch-pnvate-network-ind-01 [84]: The 
SIP P-Private-Network-lndication private-header (P-Header) 


77 


87 


cl 


81 


IETF RFC 5502 [85]: the SIP P-Served-User private header 


78 


88 


c2 


83 


draft-dawes-sipping-debug-04 [87]: the P-Debug-ID header 
extension 


80 


90 





84 


IETF RFC 6228 [88]: the 199 (Early Dialog Terminated) 
response code 


81 


91 


m 


85 


IETF RFC 5621 [89]: message body handling in SIP 


82 


92 


m 


86 


IETF RFC 6223 [90]: indication of support for keep-alive 


83 


93 





87 


IETF RFC 5552 [91]: SIP Interface to VoiceXML Media 
Services 


84 


94 


n/a 


88 


IETF RFC 3862 [92]: common presence and instant 
messaging (GRIM): message format 


85 


95 





89 


IETF RFC 5438 [93]: instant message disposition notification 


86 


96 





90 


IETF RFC 5373 [94]: requesting answering modes for SIP 
(Answer-Mode and Priv-Answer-Mode header fields) 


87 


97, 97A 







Void 








92 


IETF RFC 3959 [96]: the early session disposition type for 
SIP 


89 


99 





93 


1 £j. 1 L i ' 1 1 ' V II' I. 

draft-rosenberg-sipcore-target-un-delivery [97]: delivery of 
Request-URI targets to user agents 


90 


100 


n/a 


94 


draft-kaplan-sip-session-id-02 [124]: The Session-ID header 


91 


101 





95 


IETF RFC 6026 [125]: correct transaction handling for 200 
responses to Session Initiation Protocol INVITE requests 


92 


102 


m 


96 


IETF RFC 5658 [126]: addressing Record-Route issues in 
the Session Initiation Protocol (SIP) 


93 


103 





97 


IETF RFC 5954 [127]: essential correction for IPv6 ABNF 
and URI comparison in IETF RFC 3261 [13] 


94 


104 


m 


98 


IETF RFC 4488 [132]: suppression of session initiation 


95 


105 


c5 
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protocol REFER method implicit subscription 








99 


draft-ietf-salud-alert-info-urns [133]: Alert-Info URNs for the 
Session Initiation Protocol 


96 


106 





100 


Subclause 3.1 of 3GPP TS 24.229: multiple registrations 


97 


107 


c2 


101 


IETF RFC 4538 [135]: request authorization through dialog 
Identification in the session initiation protocol (Target-Dialog 
header field) 


99 


109 






c1 : m in case of roaming ll-NNI, else o 
c2: m in case of roaming ll-NNI, else n/a 
c3: in case of roaming ll-NNI, else n/a 



c4: m in case of trust relationship between the interconnected networks, else n/a 

c5: m in the case the REFER request is supported, else n/a 

NOTE 1 : The item numbering corresponds to the one provided in table A. 4 in [5] 
NOTE 2: The item numbering corresponds to the one provided in table A. 162 in [5] 
NOTE 3: A common URI namespace is required to apply this feature on the ll-NNI 



Table 6.1.3.2: Key to notation codes for major capabilities 



Notation 
code 


Notation name 


Explanation 


m 


mandatory 


The capability shall be supported at ll-NNI. 

SIP message relating to this capability shall be sent over the ll-NNI if received from 
the serving network, unless they also make use of other unsupported capabilities. 
SIP headers or other information elements relating to this capability shall be passed 
over the ll-NNI if received from the sending side. 

This does not imply that network elements inside the serving network or served 
network or user equipment connected to these networks shall support this capability. 





optional 


The capability may or may not be supported at ll-NNI. The support of the capability is 
provided based on bilateral agreement between the operators. 


n/a 


not applicable 


It is impossible to use/support the capability at the ll-NNI. 


c 

<integer> 


conditional 


The support of the capability ("m", "o" or "n/a") depends on the support of other 
optional or conditional items. <integer> is the identifier of the conditional expression. 



6.2 Control Plane Transport 
6.2.1 General 

The control plane transport of the U-NNl shall comply with Clause 4.2A of 3GPP TS 24.229 [5]. 

Support of SCTP as specified in IETF RFC 4168 [27] is optional for an IBCF connected by II-NNI. Nevertheless this 
option is favourable if the operators would like to improve reliability over the Ici. 



7 User plane Interconnection 
7.1 Media an(d Codec 

For "end-to-end" media session involving the II-NNI, the SIP/SDP codec negotiation procedure can be applied between 
IM CN subsystems using different media codecs. It is possible that the end-to-end codec negotiation could fail because 
no common codec could be supported by the UEs, in particular for voice services. 

To enhance interoperability, the IBCF, the MRFC, or other IMS network entities can interfere with the end-to-end 
codec negotiation to offer additional codec(s) available via transcoding, or to remove codecs. The IBCF can configure 
an attached TrGW to transcode, and the MRFC can configure an attached MRFP to transcode. 

Codecs applicable at the NNl may be a subject of interworking agreements. 

NOTE: Possible codecs which could be used at the II-NNI are described in 3GPP TS 26. 1 14 [1 1] and ETSI TS 
181 005 [12]. 
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However, to avoid that transcoding is performed several times, applicable codecs at the NNI should be restricted as 
little as possible. 

NOTE: Transcoding can be performed in an IMS network serving an SDP offerer or in an IMS network serving 
an SDP answerer. To avoid that transcoding is performed multiple times, inter-operator agreements can 
clarify if it is preferred that IMS network serving an SDP offerer or IMS network serving an SDP 
answerer modify an SDP offer to offer transcoding. 

If the IBCF performs media transcoding control, it shall apply the related procedures in 3GPP TS 24.229 [5]. 



7.2 User Plane Transport 

The user plane transport of the II-NNI may use the protocols listed in Table 7.2.1. The used protocols to transport media 
are negotiated by means of SDP offer/answer. 



Table 7.2.1 : Supported transport-level RFCs to be described In SIP/SDP messages 



Item 


RFC 


Title 


Support 


1 


IETF RFC 3550 [137] 


RTP: A Transport Protocol for Real-Time Applications 


Mandatory 


2 


IETF RFC 768 [138] 


User Datagram Protocol 


Mandatory 


3 


IETF RFC 3551 [139] 


RTP Profile for Audio and Video Conferences with Minimal Control 


Mandatory 


4 


IETF RFC 3556 [140] 


Session Description Protocol (SDP) Bandwidth Modifiers for RTP 
Control Protocol (RTCP) Bandwidth 


Mandatory 


5 


IETF RFC 4585 [141] 


Extended RTP Profile for Real-time Transport Control Protocol 
(RTCP) - Based Feedback (RTP/AVPF) 


Optional 
(NOTE 1) 


6 


IETF RFC 793 [142] 


Transmission Control Protocol 


Optional 
(NOTE 2) 


NOTE 1 : used by MTSI, as indicated in 3GPP TS 26.1 14 [11] 
NOTE 2: used for MSRP service 



8 Numbering, Naming and Addressing 

The following URI formats in SIP messages may be applied at the Ici as standardized in 3GPP TS 24.229 [5]: 

• SIP URI defined in IETF RFC 3261 [13]; 

• tel URI defined in IETF RFC 3966 [14]; 

• IM URI defined in IETF RFC 3860 [15]; 

• PRES URI defined in IETF RFC 3859 [ 16] . 

Moreover, in case of MSRP sessions passing through the II-NNI, the MSRP URI may be also used at the Ici in the SDP 
exchange, following the formats defined in IETF RFC 4975 [17]. 

According to 3GPP TS 24.229 [5], the IBCF acting as an exit or entry point in the IMS network supports these URI 
formats. These URI formats shall be supported at the II-NNI. Other URI formats may be supported over the II-NNI 
depending on the operators' agreements. 

A global number as defined in IETF RFC 3966 [14] shall be used in a tel-URI or in the user portion of a SIP URI with 
the user=phone parameter when conveyed via a non-roaming II-NNI in the Request-URI and in the P-Asserted-Identity 
header field, except when agreement exists between the operators to also allow other kinds of numbers. 

NOTE 1: In a SIP URI the user portion of the Request-URI represents a telephone number only if the SIP URI 
includes the user=phone parameter. 

NOTE 2: Agreements can exist between operators to allow non-global number (e.g. national service numbers. 

business trunking numbers, or private numbers) at a non-roaming II-NNI. A SIP URI with such a number, 
a user=phone parameter, and a phone-context parameter agreed between the operators can then be used. 
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NOTE 3: 3GPP TS 24.229 [5] allows to restrict the number within a SIP Request-URI with user=phone parameter 
at a non-roaming II-NNI to be a global number (i.e. E.164 in international format) via an appropriate 
Application Server. Suitable configuration by the operator is needed to achieve the desired modification 
of the format. 

NOTE 4: The allowed phone number formats in the P-Asserted-Identity header field of a served user are configured 
by the operator. According to 3GPP TS 23.003 [35], international E.164 format is used within a P- 
Asserted-Identity header field. 

NOTE 5: The global number format usage within a SIP Request-URI with the user=phone parameter at a non- 
roaming II-NNI allows the terminating network to find the called subscriber, via HSS interrogation, 
without any further number translation and thus improves the success of the interconnection between IMS 
Operators. 

The optional "oU" and "cpc" tel URI parameters associated with a tel URI or a SIP URI with user=phone are 
described in 3GPP TS 24.229 [5] and can be part of the P-Asserted-Identity header field. Depending on operator 
agreements, those URI parameters may be supported at the non-roaming II-NNI. 

The "sos" SIP URI parameter associated with a URI in the Contact header field of a REGISTER request or 200 OK 
response to REGISTER request is described in 3GPP TS 24.229 [5]. The" sos" SIP URI parameter shall be supported at 
the roaming II-NNI. 

The "m" and "npdi" number portability parameters for the tel URI and the SIP URI with user=phone as described 
within IETF RFC 4694 [75] can be part of the Request-URI. Depending on operator agreements these parameters may 

be exchanged over the non-roaming II-NNI. 

NOTE 6: The "rn" and "npdi" parameters can be used to address the entry point of the terminating operator 
depending on national rules for number portability. 



9 IP Version 

The network elements interconnected by means of the II-NNI may support IPv4 only, IPv6 only or both. 

The support of one or both of the IP versions is an operator option and should be based on bilateral agreement. 

In case IPv4 and IPv6 networks are interconnected, the involved IBCFs and TrGWs shall apply the IP version 
interworking procedures as indicated in 3GPP TS 29.162 [8]. 



10 Security 

The supported security mechanisms for IP signalling transport over II-NNI interfaces are described in 3GPP TS 33.210 
[10]. 



1 1 Charging 

The accounting information to be supported over the Ici is described in 3GPP TS 32.260 [29]. It shall be configurable 
by the operator to use or not the accounting mechanisms provided by the IBCF. 
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12 Supplementary services associated with the IIVIS 
multimedia telephony communication service 

12.1 General 

In order to assure the end-to-end service interoperability through the Inter-IMS Network to Network Interface (II-NNI), 
the associated supplementary services of the multimedia telephony communication service may be supported on the II- 
NNI between the two IMS networks. 

The MMTel communication service is identified by means of the media feature tag H-g.3gpp.icsi-ref set to "um:urn- 
7:3gpp-service.ims.icsi.mmtel". The media feature tag can appear in the Contact header field, the Accept-Contact 
header field and the P-Asserted-Service header field. 

The support of each associated supplementary service is based on agreement between operators. 

If a supplementary service is supported, the related procedures from the 3GPP TS 22.173 [30], the protocol details from 
the 3GPP TS 24.173 [31] and specifications referenced in the later specification shall be applied with the requirements 
in the relevant subclause due to the crossing of the II-NNI. 

12.2 Malicious Communication IDentification (MCID) 

Service specific requirements in accordance with 3GPP TS 24.616 [33] shall be supported over the II-NNI. 

The P-Asserted-Identity header field shall be supported at the 11-NNI. 

The INFO request and the 200 (OK) response to the INFO request containing the "application/vnd.etsi.mcid-nxml" 
MIME body defined in 3GPP TS 24.616 [33] may be supported at the H-NNI. 

If a network terminating the dialog supports MCID, the terminating network shall only deliver the MCID request in the" 
application/ mcid-nxml " MIME body, as specified in the 3GPP TS 24.616 [33], if an agreement to use the MCID 
supplementary service according to the 3GPP TS 24.616 [33] exists with the network originating the dialog and if the 
INVITE request received by the terminating network does not contain the information of the originating party. 

NOTE: The IBCF and the AS in the terminating network interact to deliver the MCID request only if an 

agreement to use the MCID supplementary service exists, as specified in 3GPP TS 24.616 [33] and 3GPP 
TS 24.229 [5]. 

The originating network and the terminating network shall have a bilateral agreement to support transportation of the 
minimum information specified in subclause 4.5.2.5.0 of the 3GPP TS 24.616 [33] between the networks. 

12.3 Originating Identification Presentation (OIP) and Originating 
Identification Restriction (OIR) 

Service specific requirements in accordance with 3GPP TS 24.607 [32] shall be supported over the II-NNI. 

The P-Asserted-Identity header field and the Privacy header field with values "id", "user", "none", "header" and 
"critical" shall be supported at the II-NNI. 

NOTE 1: P-Asserted-Identity header fields are intended for end-to-end operation. Removal of such header fields 
will impact the intended end-to-end operation between the end users. Where a trust relationship exists on 
the P-Asserted-Identity header field between the two IMS networks, this header field cannot be altered 
when passing through the 11-NNl according to 3GPP TS 24.229 [5]. Where no trust relationship exists on 
the P-Asserted-Identity header field between the two IMS networks, the P-Asserted-Identity header field 
will be removed by the IBCF of the originating network prior passing through the II-NNI according to the 
3GPP TS 24.229 [5]. The IBCF determines whether to remove the P-Asserted-ldentity header field 
according to procedures in 3GPP TS 24.229 [5] clause 4.4.2 referencing IETF RFC 3325 [44]. 

The option tag "from-change" in the Supported header field should be supported at II-NNI. 
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NOTE 2: The From header field cannot be altered when passing through the II-NNI and will be passed 

transparently by the IBCF. If a request is received by the terminating network and the application of the 
OIR service is required with the value "user" for the Privacy header field then the From header field will 
be anonymised in accordance with IETF RFC 3323 [34] by the terminating network. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.4 Terminating Identification Presentation (TIP) and 
Terminating Identification Restriction (TIR) 

Service specific requirements in accordance with 3GPP TS 24.608 [113] shall be supported over the II-NNI. 

The P-Asserted-Identity header field and the Privacy header field with values "id", "user", "none", "header" and 
"critical" shall be supported at the II-NNI. 

NOTE: P-Asserted-ldentity header fields are intended for end-to-end operation. Removal of such header fields 
will impact the intended end-to-end operation between the end users. Where a trust relationship exists on 
the P-Asserted-Identity header field between the two IMS networks, this header field cannot be altered 
when passing through the II-NNI according to 3GPP TS 24.229 [5]. 

Where no trust relationship exists on the P-Asserted-ldentity header field between the two IMS networks, 
the P-Asserted-Identity header field will be removed by the IBCF of the originating network prior passing 
through the II-NNI according to the 3GPP TS 24.229 [5]. The IBCF determines whether to remove the P- 
Asserted-ldentity header field according to procedures in 3GPP TS 24.229 [5] clause 4.4.2 referencing 
IETF RFC 3325 [44]. 

12.5 Anonymous Communication Rejection (ACR) 

Service specific requirements in accordance with 3GPP TS 24.61 1 [1 14] shall be supported over the II-NNI. 
The P-Asserted-Identity header field and the Privacy header field shall be supported at the II-NNI. 
Procedures as described in subclause 12.21.2 are used to provide announcements. 
The response code 433 (Anonymity Disallowed) shall be supported at the II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming 11-NNI. 

12.6 Communication Diversion (CDIV) 

Service specific requirements in accordance with 3GPP TS 24.604 [1 17] shall be supported over the 11-NNl. 

NOTE 1: The support of the Diversion header field not adopted in 3GPP TS 24.604 requires bilateral agreement 
between the operators. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

The Privacy header field with value "history" shall be supported at the 11-NNl. 

The History-Info header field as described by 3GPP TS 24.604 [117] and the Cause-Codes as defined by the 
IETF RFC 4458 [58] shall be supported over the H-NNI. 

The response code 181 (Call Is Being Forwarded) shall be supported at the 11-NNl. 

The SUBSCRIBE requests with the event package name "comm-div-info" and the NOTIFY request procedure as 
specified in IETF RFC 3265 [20] and 3GPP TS 24.229 [5] shall be supported at the roaming II-NNI if CDIVN is 
provided. 

The MESSAGE request procedure as specified in IETF RFC 3428 [19] and 3GPP TS 24.229 [5] should be supported at 
the roaming II-NNI if CDIVN is provided. 

NOTE 2: The content of the MESSAGE request is operator specific. 
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SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.7 Communication Waiting (CW) 

Service specific requirements in accordance with 3GPP TS 24.615 [37] shall be supported over the II-NNI. 

The "application/vnd.3gpp.cw+xml" MIME body defined in 3GPP TS 24.615 [37] in the INVITE request shall be 
supported at the roaming II-NNI. 

The Alert-Info header field set to "urn: alert: service: call- waiting" in a 180 (Ringing) response shall be supported at the 
Il-NNl. 

As a network option, in case of expiry of the CW timer, the response code 480 (Temporarily Unavailable) including a 
Reason header field set to cause 19 shall be supported at the non-roaming II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

12.8 Communication HOLD (HOLD) 

Service specific requirements in accordance with 3GPP TS 24.610 [36] shall be supported over the 11-NNI. 

NOTE: The support of an alternative method not adopted in 3GPP TS 24.610 requires bilateral agreement 
between the operators and is outside the scope of the present document. 

Procedures as described in subclause 12.21.3 are used to provide announcements. 

12.9 IVIessage Waiting Indication (IVIWI) 

Service specific requirements in accordance with 3GPP TS 24.606 [1 12] shall be supported over the II-NNI. 

The event package name "message-summary" according to IETF RFC 3265 [20] and 3GPP TS 24.229 [5] in the 
SUBSCRIBE request shall be supported at the roaming 11-NNl. 

The application/simple-message-summary+xml MIME body described in 3GPP TS 24.606 [1 12] in the NOTIFY 
request shall be supported at the roaming II-NNI. 

12.10 Communication Barring (CB) 

12.10.1 Incoming Communication Barring (ICB) 

Service specific requirements in accordance with 3GPP TS 24.611 [114] shall be supported over the II-NNI. 
Procedures as described in subclause 12.21.2 are used to provide announcements. 

The response code 603 (Decline) including a Reason header field as described in 3GPP TS 24.61 1 [1 14] shall be 
supported at the II-NNI. 

A Reason header field as described in 3GPP TS 24.611 [114] included in the BYE request shall be supported at the II- 
NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.10.2 Outgoing Communication Barring (OCB) 

Service specific requirements in accordance with 3GPP TS 24.611 [114] shall be supported over the II-NNI. 
Procedures as described in subclause 12.21.2 are used to provide announcements. 

The response code 603 (Decline) including a Reason header field as described in 3GPP TS 24.61 1 [114] shall be 
supported at the roaming II-NNI. 
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SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.1 1 Completion of Communications to Busy Subscriber (CCBS) 

Service specific requirements in accordance with 3GPP TS 24.642 [109] shall be supported over the II-NNI. 

The response code 486 (Busy Here) containing a Call-Info header field with a "purpose" header field parameter set to 
"call-completion" and the "m" parameter set to "BS" shall be supported at the non-roaming II-NNI. 

For invoking and revoking of the CCBS supplementary service, announcement procedures shall be used to provide 
announcements and inband-interaction procedures as described in subclause 12.21.2 shall be supported at the roaming 
n-NNI. 

The response code 199 (Early Dialog Terminated) shall be supported at the roaming II-NNI. 

Basic call procedures and in case of a call-completion recall initiated by a REFER request, normal REFER method 
handling procedures according to 3GPP TS 24.229 [5] shall be supported at the roaming II-NNI. 

As a network option the special REFER request handUng procedures according to 3GPP TS 24.628 [38] should be 
supported at the roaming II-NNI. 

NOTE 1 : 3"* party call control procedures can be used when the REFER request is not supported at the II-NNI. 

NOTE 2: A REFER request can be rejected by IBCF based on operator pohcy as specified by 3GPP TS 24.229 [5]. 

The SUBSCRIBE and NOTIFY methods according to IETF RFC 3265 [20] and 3GPP TS 24.229 [5] containing the 
event package name "call-completion" and the Call-Info header field with a purpose parameter set to 'call-completion' 
and the m parameter set to "BS" shall be supported at the non-roaming 11-NNl. 

The Request-URI with the "m" SIP URI parameter with a value set to "BS" and the Call-Info header field with a 
purpose parameter set to 'call-completion' and the "m" parameter set to "BS" in the INVITE method shall be supported 
at the non-roiuning II-NNI. 

The Date header field in the 486 (Busy Here) response to the INVITE request shall be supported at the roaming II-NNI. 
SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.12 Completion of Communications by No Reply (CCNR) 

Service specific requirements in accordance with 3GPP TS 24.642 [109] shall be supported over the 11-NNl. 

The response code 180 (Ringing) containing a Call-Info header field with a purpose parameter set to 'call-completion' 
and the "m" parameter set to "NR" shall be supported at the non-roaming II-NNI. 

For invoking and revoking of the CCNR supplementary service, announcement procedures shall be used to provide 
announcements and inband-interaction procedures as described in subclause 12.21.2 shall be supported at the roaming 
II-NNI. 

The response code 199 (Early Dialog Terminated) shall be supported at the roaming II-NNI. 

Basic call procedures and in case of a call-completion recall initiated by a REFER request, normal REFER method 
handling procedures according to 3GPP TS 24.229 [5] shall be supported at the roaming 11-NNl. 

As a network option the special REFER request handhng procedures according to 3GPP TS 24.628 [38] should be 
supported at the roaming 11-NNI. 

NOTE 1 : 3rd party call control procedures can be used when the REFER request is not supported at the 11-NNl. 

NOTE 2: A REFER request can be rejected by IBCF based on operator policy as specified by 3GPP TS 24.229 [5]. 

The SUBSCRIBE and NOTIFY methods according to IETF RFC 3265 [20] and 3GPP TS 24.229 [5] containing the 
event package name "call-completion" and the Call-Info header field with a purpose parameter set to 'call-completion' 
and the m parameter set to "NR" shall be supported at the non-roaming II-NNI. 
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The Request-URI with the "m" SIP URI parameter with a value set to "NR" and the Call-Info header field with a 
purpose parameter set to 'call-completion' and the "m" parameter set to "NR" in the INVITE method shall be supported 
at the non-roaming II-NNI. 

The Date header field in the 480 (Temporarily Unavailable) response to the INVITE request shall be supported at the 
roaming II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.13 Explicit Communication Transfer (ECT) 

Service specific requirements in accordance with 3GPP TS 24.629 [116] shall be supported over the II-NNI. 

The REFER method, the Referred-By header field and the Replaces header field as specified in 3GPP TS 24.629 [116] 
and the NOTIFY method containing an " application/sipfiag " MIME body shall be supported at the II-NNI for call 

transfer without third party call control. 

The REFER method, the Referred-By header field and the Replaces header field as specified in 3GPP TS 24.629 [116] 
and the NOTIFY method containing an " apphcation/sipfrag " MIME body shall be supported at the roaming II-NNI for 
call transfer with third party call control. 

The Refer-To URI header parameter in the REFER request containing the Require header field set to "replaces" shall be 
supported at the roaming II-NNI. 

The Replaces header field in the INVITE request shall be supported at the non-roaming II-NNI. 

12.14 Customized Alerting Tone (CAT) 

Service specific requirements in accordance with 3GPP TS 24.182 [129] shall be supported over the II-NNI. 

The P-Early-Media header field in as described in 3GPP TS 24.182 [129] shall be supported at the U-NNI. 

The response code 183 (Session Progress) including a P-Early-Media header field shall be supported over the II-NNI. 

The response code 199 (Early Dialog Terminated) shall be supported over the 11-NNl. 

The Supported header field and the Require header field with "early-session" option-tag may be supported at the II- 
NNI. 

An " application/sdp " MIME body with the Content-Disposition set to "early-session" as specified in IETF RFC 3959 
[96] may be supported at n-NNI. 

The SIP INFO mechanism for DTMF transport, as defined in 3GPP TS 24.229 [5] may be supported at the II-NNI. 

NOTE 1: For telephone-event based DTMF transport, the DTMF digits are sent as media and not visible in the 
control plane. 

NOTE 2: Multiple methods for DTMF transport are defined in 3GPP TS 24.182 [129]. 
SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.15 Customized Ringing Signal (CRS) 

Service specific requirements in accordance with 3GPP TS 24.183 [98] shall be supported over the 11-NNl. 

An Alert-Info header field in the initial INVITE request containing an URI followed by a URN "urn:alert:service:crs" 
shall be supported at the II-NNI. 

A Contact header field in the initial INVITE request containing a "g.3gpp.crs" feature tag may be supported at the II- 
NNI. 

The Supported header field and the Require header field with "early-session" option-tag may be supported at the II- 
NNI. 
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An " application/sdp " MIME body with the Content- Disposition set to "early-session" as specified in IETF RFC 3959 
[96] may be supported at II-NNI. 

The SIP INFO mechanism for DTMF transport, as defined in 3GPP TS 24.229 [5] may be supported at the II-NNI. 

NOTE: For telephone-event based DTMF transport, the DTMF digits are sent as media and not visible in the 
control plane. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.16 Closed User Group (CUG) 

Service specific requirements in accordance with 3GPP TS 24.654 [103] shall be supported over the II-NNI. 

The "application/vnd.etsi.cug+xml" MIME body as specified 3GPP TS 24.654 [103] shall be supported in INVITE 

requests at the II-NNI. 

NOTE: If no agreement between the originating network and the terminating network exists to support the CUG 
supplementary service the INVITE request is rejected as described in IETF RFC 5621 [89] when the 
"handling" parameter in the Content-Disposition of the " appUcation/vnd.etsi.cug-Hxml" MIME body is set 
to "required". 

The 403 (Forbidden) response, the 603 (Decline) response and the 500 (Server Internal Error) response shall be 
supported at II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.17 Personal Network Management (PNM) 

Service specific requirements in accordance with 3GPP TS 24.259 |99| shall be supported over the II-NNI. 

The Contact header field of the REGISTER request containing the g.3gpp.iari_ref feature tag with the value um:um- 
7:3gpp-application.ims.iari.pnm-controller shall be supported at the roaming II-NNI. 

The Accept-Contact header field containing a g.3gpp.iari_ref feature tag with the value urn:urn-7:3gpp- 
appUcation.ims.iari.prmi-controIler shall be supported at the II-NNI. 

The History-Info header field and Supported header field containing the "histinfo" option tag as described by 3GPP TS 
24.259 [99] shall be supported at II-NNI. 

12.18 Three-Party (3PTY) 

Service specific requirements in accordance with 3GPP TS 24.605 [105] shall be supported over the II-NNI. 

NOTE 1: The requirements below can be relaxed by bilateral agreements between operators. 

The requirements for the 3PTY supplementary service are the same as for the CONF supplementary service specified in 
subclause 12.19 with the following additional requirement: 

- If a REFER request is supported at the II-NNI, a Replaces header field in the header portion of the SIP URI of 
the Refer-to header field of the REFER request shall also be supported at II-NNI. 

NOTE 2: Subclause 12.19 describes the conditions for the support of the REFER request. 

12.19 Conference (CONF) 

Service specific requirements in accordance with 3GPP TS 24.605 [105] shall be supported over the II-NNI. 
NOTE 1: The requirements below can be relaxed by bilateral agreements between operators. 
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The REFER request shall be supported at the roaming II-NNI in the direction from visited to home network. Based on 
inter-operator agreement, the REFER request may be supported at the non-roaming II-NNI, and at the roaming II-NNI 
in the direction from home network to visited network. 

NOTE 2: If the REFER request is not supported at the non-roaming II-NNI, or at the roaming II-NNI in the 

direction from home network to visited network, an attempt of an UE to send the REFER directly to peers 
to invite them to a conference without involvement of the conference focus can fail over such an II-NNI. 
However such failures can also occur if a peer is located in a circuit switched network, or if a peer does 
not support the REFER method. An operator can avoid such failures by configuring an AS to convert the 
REFER to an INVITE, as detailed in 3GPP TS 24.628 [38]. Information on security risks associated with 
the REFER request is provided within the security consideration" of IETF RFC 3515 [22]. 

NOTE 2: A REFER request can be rejected by IBCF based on operator poUcy as specified by 3GPP TS 24.229 [5]. 

The application/resource-lists+xml MIME body shall be supported at the roaming II-NNI. 

The Referred-By header field in the INVITE request shall be supported at the II-NNI. 

The "isfocus" feature parameter indicated in Contact header field of the INVITE request and in the 200 (OK) response 
shall be supported at the II-NNI. 

The SUBSCRIBE request including the "conference" event package name in the Event header field and the NOTIFY 
request procedures according to 3GPP TS 24.147 [106] shall be supported at the II-NNI. 

The AIIow-Events header field with the value "conference" shall be supported at the roaming II-NNI and may be 
supported at the non-roaming II-NNI. 

1 2.20 Flexible Alerting (FA) 

Service specific requirements in accordance with 3GPP TS 24.239 [lOI] shall be supported over the II-NNI. 
The 486 (Busy Here) response code shall be supported at the II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.21 Announcements 

12.21.1 General 

Announcements may be provided during the establishment of a communication session or during an established 
communication session. Both of them shall be managed over the II-NNI. 

1 2.21 .2 Providing announcements during the establishment of a 
communication session 

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements. 

The P-Early-Media header authorizing early media as defined in IETF RFC 5009 [74] during the estabhshment of a 
communication fields shall be supported at the II-NNI. 

The Alert-Info header in the 1 80 (Ringing) response to the INVITE request during the establishment of a 
conmiunication, should be supported at the II-NNI. 

NOTE: The IBCF can decide to remove the Alert-Info header field if required by local policy. 

1 2.21 .3 Providing announcements during an established communication 
session 

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements. 
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In case of provision of an announcement to a user over the II-NNI during an established communication, the Call-Info 
header field in a re-INVITE request should be supported at the II-NNI. 

NOTE 1 : An alternative method to provide announcements is to use the existing media stream. 

NOTE 2: The IBCF can decide to remove the CaU-Info header field if required by local poUcy. 

1 2.21 .4 Providing announcements winen communication request is rejected 

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements when a communication request is 
rejected. 

There are three methods defined in 3GPP TS 24.628 [38] to provide the announcement: 

1) sending an announcemt as an early media; 

2) return an Error-Info header field; and 

3) accept the communication request and then provide the announcement. 

NOTE 1 : The II-NNI requirements for accepting the communication request and then provide the announcement is 
not within the scope of this subclause. 

The P-Early-Media header field authorizing early media as defined in IETF RFC 5009 [74] and the Reason header field 
with the proper cause value shall be supported at the II-NNI. 

NOTE 2: There are 2 methods to use early media for sending the announcement in-band. First method is the 

gateway model defined by IETF RFC 3960 [136], second method is described in 3GPP TS 24.628 [38] 
Annex D. 

The Error-Info header field in the 3xx, 4xx, 5xx or 6xx response to the INVITE request when rejecting the 
communication request, should be supported at the II-NNI. 

NOTE 3: The IBCF can decide to remove the Error-Info header field if required by local policy. 

1 2.22 Advice of Charge (AOC) 

Service specific requirements in accordance with 3GPP TS 24.647 [122] shall be supported over the II-NNI. 

The Accept header field with "application/vnd.etsi.aoc-Hxml" shall be supported at the roaming II-NNI. 

The INVITE method containing an application/vnd.etsi.aoc-Hxml" MIME body shall be supported at the roaming II- 
NNI. 

Ixx provisional responses and the 200 (OK) response to the initial INVITE request containing an 
application/vnd.etsi.aocH-xml MIME body shall be supported at the roaming II-NNI. 

The INFO method containing an appUcation/vnd.etsi.aocH-xml MIME body shall be supported at the roaming II-NNI. 
The response code 504 (Server Time-out) shall be supported at the II-NNI. 

A Reason header field with a reason value with the protocol set to "SIP" and the cause set to "504" and a reason value 
with the protocol set to "Q.850" and the cause set to "31" in the BYE method shall be supported at the II-NNI. 

An apphcation/vnd.etsi.aoc+xml MIME body in the BYE request or the final response to the BYE request shall be 
supported over the roaming II-NNI. 
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Annex A (informative): 
Summary of SIP header fields 

A summary of the SIP header fields to be used in case of interconnection by using II-NNI is proposed in Table A.l. 

The starting point is the sending behaviour described for proxy and UA roles in Annex A of 3GPP TS 24.229 [5]. In 
case of misalignment between Table A.l and the behaviour described in 3GPP TS 24.229 [5J, the behaviour in 3GPP 
TS 24.229 [5] has the precedence. In case a header field is not described in Table A.l and it is described in 3GPP TS 
24.229 [5], the description in 3GPP TS 24.229 [5] is applicable over II-NNI. 

The notation of the codes used for the SIP headers listed in table A. I has a different meaning to the one proposed for the 
SIP messages. The definition of these terms is provided in table A.2. 
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Table A.1 : Supported header fields 
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Table A.2: Key to notation codes for SIP header fields 
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